A private network is a collection of computers administered by a single organization and installed at one or more sites for sharing information freely. Initially, the sites of a private network were connected to each other via dedicated leased lines to ensure privacy. This model was replaced by virtual private networks (VPN), which enable service providers to efficiently share their high cost infrastructure among many paying customers, while delivering customized services.
To satisfy a broad range of customers, service providers must offer subscribers different VPN service delivery models, because each subscriber has different security concerns, number of sites, users, routing complexity, traffic patterns, traffic volume, etc. The VPN models have evolved over the years with a view to better accommodate this diversity and also, to keep pace with the evolution of network communication protocols and emergence of data services. For example, Frame Relay (FR) VPNs and ATM VPNs operate at L2; MPLS-based provider provisioned VPNs (PP VPN) also operate at L2, while and BGP/MPLS or IETF RFC2547bis VPNs operate at L3.
The L3 VPN model uses BGP (border gateway protocol) to distribute the routing information across the service provider's backbone network, and uses MPLS (multi-protocol label switching) to forward VPN traffic from one VPN site to another. A customer site is connected to the service provider network by a customer edge (CE) device, which communicates with a provider edge (PE) router in the service provider network, over an access data link.
A CE device can be a host, a Layer 2 switch, or more commonly, an IP router that establishes an adjacency with its directly connected PE router, using e.g. RIPv2, OSPF, etc. A PE router may forward packets on one or more VPNs; the service provider associates each port with a virtual routing and forwarding (VRF) table to each VPN that uses the respective PE router. After the adjacency between the CE and the ingress PE router is established, the CE device advertises the site's local VPN routes to the PE router. The PE router in turn exchanges these routes as VPN-IP routing information, using BGP, with other PE routers with which BGP peers have been established. In this way, all PE routers on a VPN learn remote VPN routes from the other peer PE routers and maintain and update the routing information in the respective VRF.
A White Paper RFC 2547bis entitled “BGP/MPLS VPN Fundamentals” (Semeria et al.), describes a VPN service model for efficiently scaling the network while delivering revenue-generating, value-added services. This RFC specifies a L3 VPN service that uses BGP-4 to exchange VPN-IPv4 routes between provider edge (PE) routers, and ensures simultaneous operation of a plurality of VPNs over the same physical network, using VRFs, route distinguishers (RD) and route filtering based on route target (RT) attributes.
While this technique allows segregating the routing information between various VPNs, it introduces performance issues due to the high tax on network bandwidth consumed during route refreshes in the VRF tables triggered by changes in the routing data. A route refresh is requested by a PE router with a view to get routes from peer PE routers that could potentially match newly created/deleted VRFs import route targets at that PE. A route refresh request is sent to all connected PEs, which in turn respond by sending back the route information for all their VRFs pertinent to the respective VPN.
There is a need to efficiently setup and maintain a L3 VPN, for reducing the unnecessary bandwidth and processing resources that are consumed by the prior art approaches for updating the routes in a L3 VPN.